Over the years of computerized data processing, commercial enterprises have built large legacy databases on central computers. Desktop PCs connected via LANs, rather than dumb terminals with direct connections, have become the means of accessing these databases. Furthermore, in on-line transaction processing systems, PCs have taken on a role in the actual processing of a transaction, creating a distributed computing environment (DCE). Transaction processing monitor (TPM) programs running on central computers have also been expanded to operate in the DCE. TPMs which formerly communicated keyboard input and display output data streams, have been expanded to communicate service requests and replies. Other "server" programs have been created specifically for the DCE which communicate only service requests and replies. The standard of DCE computing has become the client-server model.
In client-server computing there is interaction between two computers usually connected by a local area network, or LAN. The first computer, the client, requests a data processing operation be performed on the second computer, or server, as a step in achieving its particular objective. For example, because legacy databases are often centralized on a medium or large scale computer, these computers often act as database servers, adding, changing, or deleting database information in response to a request from a client PC.
Server programs commonly make their services available to the client program through a remote procedure call (RPC) mechanism. The client program typically makes many procedure calls during its execution. These procedures execute on the same computer as the client program. Each procedure generally performs a small, discrete data processing operation. When a remote procedure call is made, a request to perform the procedure is transmitted across the LAN to the server computer, where the procedure is executed and some result is returned to the client.
Users too geographically distant to be directly attached to the LAN typically need to make a dial-up connection over a phone line and attach to the LAN or the server itself in order to run programs written for the DCE. Because of the limited bandwidth of switched telephone lines, this usually means a great sacrifice in speed. In many applications the speed problem is severe enough to preclude dial-up usage altogether.
At the same time that the number of LANs and client-server DCEs was rapidly expanding, so was the Internet. LANs were being interconnected into private wide area networks, or WANs. These private WANs were in turn being connected into the global WAN known as the Internet. Some private WANs are constructed using the technology base of the Internet, forming what are called intranets.
The fastest growing portion of the Internet is what is known as the World Wide Web ("WWW", or "Web", for short). The Web is built on the client-server model. Web browsers are the client programs. These browsers take a document formatted in HTML, generate its visual display, and perform any associated processing. Web servers, deliver an HTML document, or "Web page," to a Web browser when requested. With all existing Web browsers, the interaction is stateless, meaning that a Web server retains no information about a particular client with which to influence any future interactions with that client.
Gaining access to the Web is often a primary motivation behind efforts to build intranets and to get private WANs connected to the Internet. Once connected, the computer user has a high-speed connection to the world, but ironically that high speed connection most often cannot be used to connect a geographically remote user to a company server for transaction processing.
There are two main reasons why the Internet has not been used to support traditional on-line transaction processing. First, the TPM employed cannot communicate using the protocols of the Internet. Second, client applications are written dependent on operating characteristics of the LAN not shared by the Internet.
Several differences between a LAN and the Internet make TPMs suitable for LANs difficult to use with the Internet. Unlike LANs, the Internet covers an immense geography, and potentially long distances can result in slow response times. The Internet instantaneously constructs a virtual circuit for each communication with varying reliability outside the control of the user, while LANs are generally more reliable. The public nature of the Internet introduces privacy and security concerns not as relevant to LANs. Lastly, some Internet protocols are stateless and unusable for "stateful" transaction processing.
Despite these obstacles, transaction processing across the Internet has been successfully accomplished. One implementation is a "translation server" (see Perrochon, "Translation Servers: Gateways Between Stateless and Stateful Information Systems"). Translation servers are, however, directed at the "TPM to dumb terminal" model of on-line transaction processing. The translation server essentially translates the dumb-terminal display format information into HTML format for display on a Web browser. The translation server also translates user input from the browser into keyboard input for the TPM.
Another implementation of transaction processing across the Internet is an RPC gateway. This implementation is directed at the client-server model. DCE Encina Lightweight Client(TM) from Transarc Corporation is a commercial example of this methodology. In it, the gateway processor acts as an intermediary, accepting RPC requests from the client over the Internet connection. The gateway processor then forwards the request to the server application via a communication channel, protocol, and format natively acceptable to the server application. Responses from the server to the client similarly travel back through the gateway processor. Multiple, alternate gateway processors can be deployed to improve reliability.
The RPC gateway model has several disadvantages. For example, the cost of a separate gateway processor may be prohibitive if required. In addition, the potentially long response time of the Internet compared to a LAN can slow the application unacceptably. Applications which issue multiple RPCs per transaction are especially susceptible. Accordingly, while RPC gateways allow TPMs to be used on the Internet, many of the advantages TPMs bring to networks cannot be achieved using the RPC gateway model.
Consequently, being able to connect a client program with a server program across the Internet or a similar network in a way that allows for the advantages of TPMs to be utilized on the Internet would be a significant advance over existing systems.
Thus several objects of the present invention include:
allowing legacy on-line transaction processing systems to exploit Internet-like networks for client-server computing. PA1 minimizing the network traffic required to complete the server processing for a transaction. PA1 providing sophisticated use of network connections by servicing multiple clients from an individual server port. PA1 maintaining essential data about the client application state in a controlled environment on the server rather than on the client processor or in the protocol. PA1 increasing the reliability and recoverability of a transaction processing system operating over an unreliable network. PA1 providing a general purpose, high-level interface between client applications and server-based services which hides the complexity of using the service from the client application. PA1 improving the scalability of server support for clients connected via Internet-like networks. PA1 enabling deployment of client application programs which utilize commonplace Web browsers for their user interface.
The present invention provides these advantages of bringing TPMs to the Internet, and thus provides significant advantages over existing systems.